EOS: Exactly-Once E-Service Middleware

Today's web-based E-services do not handle system failures well. One of the most prominent examples is unintentional purchase of multiple copies of the same item (e.g., a DVD) in an online store. This may happen when the user sees a browser timeout for the final “checkout” (“place order”) request caused by a short outage or overload of the network or the backend servers (typically during peak load). Whereas the request may have been successfully albeit slowly processed, the user may attempt to send the check-out request once again, e.g., by hitting the browser “refresh” button, unintentionally buying another copy of the same item. Another example is a home-banking application deployed by one of the biggest German banks. This application uses a so-called PIN/TAN security procedure. Each user is identified by a personal identification number (PIN). The bank hands over a list of transaction numbers (TANs) to each user. A TAN must be provided for each home-banking transaction to be accepted. For security reasons each TAN can be used only once. The following problem may arise (and has indeed happened to customers). After the first attempt to issue a money transfer order the user perceives a long delay resulting in an error message stating “this page is currently not available”. The user re-submits the request and the “resurrected” application responds with: “A TAN was used twice. Your TAN list has been frozen. Please contact your nearest branch office if you would like to have your TANs reactivated again”. Such phenomena occur because the “stateless” interaction paradigm of the web puts the burden of managing sessions, and in particular handling failures, on application programs. Unfortunately, failure handling logic can be fairly complex, and application programs often make errors when responding to errors. In particular, they may simply forget actions already taken, not only after a successful execution but also after a system failure, so that they cannot guarantee exactly-once execution. In contrast, our approach aims to place failure handling logic into a generic Internet middleware framework so that failures are masked from application programs (and users). Application programs are thus relieved from handling message timeouts and other exceptions caused by system failures. Based on the conceptual work in [2], we have developed a prototype system, coined EOS, that uses Microsoft’s IE5 browser on the client side and the popular Apache/PHP middleware as the middle tier of three-tier Web applications. With our specific modifications to the IE5 environment and the PHP servlet engine, the EOS prototype guarantees exactly-once execution for all requests. Our modifications are transparent to the application programs: no changes are required to servlet programs (i.e., PHP scripts) and no failure handling code is required by these programs other than application-level exceptions such as “item out of stock” etc. and dealing with back end transaction aborts. As a result, all business requests, including those with non-idempotent effects, are processed such that their effects occur exactly once. This guarantee includes messages seen by applications and users as well as data updates issued to backend servers. In addition to [2], conceptual work on recovery guarantees for Internet applications includes [3,5,7]. However, to our knowledge, our prototype is the first work that provides an implemented solution.